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Foreword 

This Technical Specification has been produced by the 3^^ Generation Partnership Project (3 GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 

The present rapid development of a diversity of new applications and application environments for mobile usage creates 
a complexity of previously unseen proportions that the Mobile Equipment has to handle. 

This specification introduces a generic model approach for the ME environment; the purpose is not to categorise the 
applications / peripherals, but to try to structure the events that are internal and external to, and has to be handled by, the 
ME Core Functions. This means that the structure or grouping of the events should be made from a ME centric 
perspective. Some applications run on the ME side have counterparts in the network. This specification does not address 
the functions in the network. 
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1 Scope 



This 3GPP Technical Specification defines the principles for scheduling resources between applications in different 
application execution environment (e.g. MExE, USAT etc.) and internal and external peripherals (e.g. infra-red, 
Bluetooth, USIM, radio interface, MMI, memory etc.). 

This specification is divided in two parts: Subclause 4 defines a framework for event handling. Subclause 5 addresses 
some specific issues. 

Appendix A contains an informative background to the problem area. 



References 



The following documents contain provisions, which, through reference in this text, constitute provisions of the present 
document. 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document 
(including a GSM document), a non-specific reference implicitly refers to the latest version of that document in 
the same Release as the present document. 

[1] 3GPP TR 21.905 "3G Vocabulary" 

[2] 3GPP TS 23.057: "Mobile Station AppHcation Execution Environment (MExE); Functional 

description; Stage 2". 

[3] WAP, WAP Forum, "WAP Technical Specifications Suite", version 1.1, June 1999. 

( http://www.wapforum.com/ ) 

[4] 3GPP TS 3 1 . 101 : "UICC / Terminal Interface; Physical and Logical Characteristics" . 

[5] 3GPP TS 31.102: "Characteristics of the USIM application". 

[6] 3GPP TS 31.111: "USIM Application Toolkit (USAT)". 

[7] 3GPP TS 22.038: "Technical Specification Group Services and System Aspects ; USIM/SIM 

AppHcation Toolkit (USAT/SAT); Service description; Stage 1". 



Definitions and abbreviations 



3.1 Definitions 

For the purposes of this document the following abbreviations apply in addition to those defined in the referred 
documents: 

call: The term call means voice and data calls, USSD, SMS, fax, GPRS calls, supplementary services, etc. 

preferences: includes authorisations, priorities, options, etc. 

authorisation: means permission to set up and / or receive any call or only certain types of call and access rights to user 
data. 
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ME Core Functions: software functions that contain the central logic for the ME, including for instance the scheduling 
of events. 

3.2 Abbreviations 

For the purposes of the present document the following abbreviations apply: 

MExE: Mobile Execution Environment 

MM: Mobility Management 

RR: Radio Resource 

USAT: USIM AppHcation Toolkit 

WAP: Wireless Application Protocol 



Principles for the Framework 



The model presented in appendix A defines a framework specifying principles for event handling, with the focus on 
issues related to application interaction. Principles for the framework are given below, using the stated definitions. The 
list is not necessarily complete. 



4.1 Basic principles 



1. Irrespective of the principles given below, emergency calls shall override all other calls. 

2. The ME is the central resource and schedules internal and external entities according to the user's preferences and 
external environment . 



4.2 User requirements 



1 . The user shall have the capability to make the ultimate decisions as elaborated below. Additionally, in the case 
where an UE is unmanned, none of the issues below shall render the UE inoperable such that it requires manual 
intervention locally at the UE to restore its use. 

2. The user shall have the capability of selecting preferences interactively and / or via prior set-up in one or more user 
profiles. These shall be valid on a global or on a per application basis. The user's preferences shall be retained even 
in the event of loss of power. 

Preferences can be selected for an application when it is installed, or at any other time thereafter. 

Preferences, notably but not exclusively the priorities, can be modified at any time and this shall have effect at the 

earliest possible opportunity thereafter. 

3. The user shall have the capability to modify authorisations assigned to applications. These shall be valid on a 
global or on a per application basis in one or more user profiles. 

4. The user shall have the option to be advised to what extent an application has been authenticated at installation- 
time, and prevent the application from being installed based on this advice. 

The user shall have the option to be advised about the integrity of an application at installation-time, and prevent 
the application from being installed based on this advice. 

5. The user shall have the capability to abort or suspend any on-going call that has been set up automatically by an 
application. 

6. The user shall have the capability to require that the ME request permission from the user for individual calls, sets 
of calls (for instance all calls by a certain application) or all calls. The user shall have the capability to request the 
ME to record information on individual calls, sets of calls or all calls. 

7. The user shall have the capability to distinguish which entity / application caused a specific event. The ME uses 
this information to support the user's preferences. The ME shall be able to inform the network of entity / 
application at set up time to support trace-ability when a call is set up. 



ETSI 



3GPP TS 23.227 version 4.0.0 Release 4 7 ETSI TS 1 23 227 V4.0.0 (2001 -03) 



8. The user's privacy shall be protected. Access to user data (including user profiles and any personal information in 
the UE) and audio functions (this would prevent for instance a mechanism that allows eavesdropping) shall not be 
possible without the user's prior permission. 

9. The user shall have the capability to request from the ME which applications are present in the MExE environment 
and the (U)SIM, and whether they are running. The user shall also have the capability to request from the ME the 
status of other interfaces as shown in Figure 1 , where implemented. 

4.3 Additional requirements on applications 

1. An application shall not assume that it is the only one active. For example where several applications use the same 
interface the application and / or the protocols used over the interface must be able to handle contention. 

2. An application shall not interfere (terminate, suspend or degrade) with on-going calls set up by another application 
without authorisation from the user. For certain combinations of call (e.g., voice/data and USSD messages), 
interference can happen resulting in a level of degradation. 

3. An application shall not assume that it has priority over another application, and shall comply with the user's 
currently selected preferences. 

4.4 Additional requirements on the ME 

1 . The ME shall have the capability to authenticate the source of the application. 

2. The ME shall have the capability to assure the integrity of an application. 

5 Specific Interaction Requirennents 

The following sections detail specific interaction requirements. 

5.1 Bearer Independent Data Transfer 

Bearer Independent Data Transfer is a USIM feature that allows the USIM to request the ME to set up and manage a 
data channel (using a CSD, GPRS, SMS or USSD bearer) using information provided by the USIM. Once the call is 
established, data may be transferred through that data call. The details for the USIM/ME interface are specified in 
3GPP TS 31.101 [4], 31.102 [5], and 31.111 [6]. The Service Requirements for this are specified in 3GPP TS 22.038 
[7]. 

5.1 .1 Interaction between Core ME functions and Bearer Independent 
Data Transfer Service 

When a Bearer Independent Data Transfer Service is requested by the USIM, the ME shall: 

• If the ME is idle, set up the data channel as requested, indicating to the user by appropriate means, e.g., with an 
icon, that one or more calls are in progress and confirming to the USIM. 

• If the ME is not idle and can not service the request without negative impact on ongoing services, then the ME shall 
indicate to the USIM that the data channel can not be set up. However, if the user has indicated a preference for 
servicing such requests despite the negative impact then the ME may proceed as in the bullet point above. 

• If the user requests that the call be terminated via MMI or other interface, then the call shall be terminated and the 
USIM shall be informed. 

• If an external device (TE, Bluetooth device etc.) requests the same resource then that request shall be denied. 

The above behaviour may be modified by a change of user preferences, for example the user may request the ME to 
deny access by the USIM to a data channel, or the user may request the ME to prioritise a particular external device 
such that a call set up by a USIM is cleared in order for the external device to be able to make a call. 
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5.2 Services and applications external to the MT 

In the tele- and datacom community there exist today use cases for moving internal interfaces out of the MT; they are 
required to fulfil user expectations of what services and features 3G MTs should offer. 

However, discussions on security clearly show that services should be terminated in the MT, while applications can, as 
today, terminate in the TE. A possible UE functionality split should not allow internal interfaces (including USIM) to be 
moved to external interfaces, neither using USAT local link nor other interfaces. 

This is a precaution that shall be taken until suitable procedures against misuse have been found and standardised. 
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Annex A (informative): 
Interaction handling 



In this specification we illustrate possible types of interaction handling for a ME that already can be required or that 
currently are being developed in standards and industry fora. Although it is probable that only a subset of these entities 
will exist at the same time, there is no way of knowing the particular combination of applications or a particular users 
needs relative to this in advance; a general way to handle the co-existence must still be defined. 

A framework, defining general rules for handling this co-existence of several external functions is outlined in this 
document. The framework states requirements for the behaviour of the external functions as well as principles for the 
co-existence as such. As an example, several of the external functions below, or protocols used by them (e.g., the AT- 
commands) assume a one-to-one relation between them and the ME Core Functions, implying a lack of specified 
mechanisms to handle a multitask environment. 



A.1 The model approach 



The model below proposes a conceptual split, meaning that the entities and their interfaces are logical and need not 
correspond to any physical division. Before the figure is presented some clarifications and general comments are 
needed: 

• The ME Core Functions should be understood as the (collection of) software functions that contain the central logic 
for the ME, including for instance the scheduling of events. 

• With external event is meant interaction that an application / peripheral wants (requests / commands), as well as 
necessary handling of network signalling, user request via the keys, etc. External does not imply whether an 
external interface is used or not. 

• Some network signalling is easy to refer to basic network functions, such as Location Update, while other 
signalling has been invoked by an application. 

• The user can interact / intervene directly via keys, etc. This is indicated with the Manual User Interaction entity. 
The user can of course do the same via, e.g., a PC or a MExE application, but the events that such actions create is 
here viewed like the other events that these entities can create. 

• The USIM I general Smart Card Functions are split into several logical entities: the Transport Layer Security, 
meaning "basic" 2G/3G security; the USIM Application Toolkit; USIM Application Toolkit Run AT-command; 
and other functions, such as the WIM, the WAP Identity Module, that is being specified. 

• The TE, Terminal Equipment, is a PC or another piece of equipment that can run applications independently. 

• An Intelligent Peripheral could be an advanced charger or a car hands-free installation. 

• The MExE entities are as defined in [2] . 

• Other includes ME resident applications and allows for future applications, and, if that is needed for the model, 
could correspond to other external devices such as a microphone. 

• The interfaces as shown in the figure are logical. In practice the applications run in the ME, a TA or on its own 
separate platform, and the interfaces are then ME internal or external via a physical connector, IrDA, or Bluetooth. 
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Figure A.I 

The figure shows the extent of the complexity that the ME will be expected to handle. It is obvious that a generic 
framework for conflicts, error handling and interactions is needed. In particular, the following issues can be noted: 

1. Priorities of the event handling - the ME does the scheduling and this should be according to the user's 
preferences. 

2. User control - the user's wanted / required interaction; his/her knowledge and control of the events; user integrity 
for instance for personal data, the ME position, etc. 

3. Trace-ability - which entity / application has caused a particular event. This information is required input to solve 
several of the other issues. 

4. Consistency - in the actions of the ME Core Functions relative to the specific application. Several applications and 
priority levels interact. 

5. The validity of commands - for instance call validity when the ME is in the Home PLMN or roaming. 

6. Network signalling aspects - how does for instance a dual mode ME treat applications specific to only one of the 
standards. 

7. It might be necessary to look into mechanisms for rejection and termination by the ME Core Function (upon user 
choice) for applications, calls etc. 

8. Testability - the ME manufacturer must be able to as far as possible verify the behaviour of the product, and this 
should be taken into consideration when the framework is specified. Conformance testing, however, is only 
relevant to the extent that already is tested. 

9. Security aspects - for the protection of the ME and the network mechanisms like authentication of the applications 
might be required. 

Further, the entities have different characteristics; this can possibly be used by the framework definitions. The following 
can for instance be noted: 

1. Several of the entities work together with network nodes, some as slaves (e.g., SIM) and others invoking 
commands (e.g., WAP). Others, like the intelligent peripherals, only communicate "locally". 
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2. The entities can be active or passive. In the latter case the ME has more knowledge about the expected behaviour, 
since they only execute functions upon request and cannot issue commands independently. 

3. Some events refer to "basic" network handling, some to manual user interaction, and others relate to application 
invoked functions. "Basic" network interaction should then have priority if such a distinction can be made. 
Consideration should be given to incoming calls. 
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